[レポート]OSBT: OpenID Connect Scenario-Based Tester – CODE BLUE 2023 #codeblue_jp
こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。
今回はCODE BLUE 2023で行われた以下のセッションのレポートです。
OSBT: OpenID Connect Scenario-Based Tester
OpenID Connectはユーザーの属性情報をアプリケーション間で共有するための認証・認可のプロトコルであり、OAuth2.0という認可プロトコルの拡張である。OpenID Connectを用いることで、一つのサービスのアカウントを用いて複数のサービスにログインすることが可能となる。ライブラリやアプリケーションの実装者はOpenID Connectの仕様に基づいた実装を行うが、誤った実装により脆弱性を生じさせてしまうことがある。それらの脆弱性はファジングなどの自動検査手法で検出することは難しく、検出のためにはシナリオベースのテストが必要となる。既存のOpenID Connectのテストツールでは、テストシナリオがツール内部で事前に定義されているため、仕様から推測される一般的な実装ミスしか検出できず、特定の条件下でのみ発生する脆弱性を検出できないという課題がある。OIDC Scenario Based Tester (OSBT)はOpenID ConnectのテストシナリオをPythonを用いて柔軟に記述可能にすることを目的としたテストツールである。ライブラリ・アプリケーションに対して、個別最適化されたテストシナリオを記述して実行することで、特定の条件下でのみ発生する脆弱性の検出に役立てることができる。OSBTが提供するシナリオ記述ライブラリを用いて、ブラウザの自動化、プロキシサーバの操作、悪意のあるOpenIDプロバイダ (Attacker OP)の操作をプログラムで記述することができる。また、Github Actionsを用いたCIへの組み込みにも対応しており、ライブラリ・アプリケーションの継続的なセキュリティ自動評価に使用することができる。
Presented by : 湯浅 潤樹 - Junki Yuasa
ご登壇資料はこちら↓
レポート
- 登壇者の湯浅氏が作成したツール「OpenID Connect Scenario-Based Tester」についての紹介
- Social Login
- 通常のログインだとユーザーはそれぞれのサービスに紐付く認証情報を持っている
- 対してソーシャルログインでは、例えばGoogleのアカウント1つで複数サービスの認証が可能
- OpenID Connect(OIDC)
- そのうちの一つがOIDC
- 認証→トークン発行
- OAuth2.0という認証プロトコルに基づく
- OIDC Flow(Autorization code flow)の紹介
- User、RP、IdPが相互にやり取りを行い、最終的にIdPがトークンを発行する
- 複数の主体が絡むため、どこに脆弱性があるのか見つけづらい
- そのため、逐次実行するシナリオをカスタマイズする必要がある
- OIDCのシナリオを作る上での課題
- 1つ目「Test coverage」
- 実装方法に起因する脆弱性
- セッション管理が不適切
- サーバー/DBに起因するもの
- 言語/FWに起因するもの
- RP/IdPの連鎖的な悪用によって生じるもの
- RPのXSSによるIdPの認可行動の窃取
- 実装方法に起因する脆弱性
- 2つ目「シナリオのカスタマイズ性」
- シナリオの修正
- シナリオの阻害
- 途中のシナリオを実施しないなど
- シナリオの順序変更
- シナリオおける変数の利用
- 3つ目「再現性」
- 手動テストが用いられることが多い
- しかし、手順が複雑なので再現性を取るのが難しい
- 1つ目「Test coverage」
- 既存のツールでは上記の課題を全て解決しているとは言い難い
- 1つ、2つを満たしているものはある
- そこで湯浅氏が開発したのがOSBT
- https://github.com/oidc-scenario-based-tester/osbt
- 上記課題を全て解決
- テストシナリオはシナリオ記述機能で要件に基づいて作成出来る。ツールの中に組み込まれていない。
- 再現性も満たしている。
- ブラウザの操作機能
- URLの展開
- 攻撃者がユーザーに悪意のあるURLを踏ませる操作を再現
- 画面上での操作
- HTTP req/resの操作
- paramの操作
- req/resの遮断
- 履歴取得
- URLの展開
- Attacker IdP operation
- IdPが悪意を持っている場合に利用可能な機能
- Attacker server operation
- サンプルシナリオを使ったデモの紹介
- 手順は下記
- セットアップ
- リダイレクトURIを改ざんする命令を送信
- 認証フローを実行
- Attacker Serverのログを参照
- IdPがリダイレクトURIを検証しない場合、Attacker Serverにアクセスしてしまう
- 手順は下記
- 2つ目のデモシナリオ「redirect_uri session poisoning」
- 通常の認証リクエストと攻撃者の認証リクエストを同じタイミングで送信
- セッションパラメータが更新されてしまう
- OSBTはGithub Actions(CI)に組み込むことも可能
- デモで紹介
- まとめ
- 既存のツールでは微妙に手が届かない部分(高いシナリオのカスタマイズ性など)があった
- それを解決するために、研究の一環としてOSBTを作った
感想
既存のものでは微妙に使い勝手が悪かったという課題を洗い出し、その課題を解決したツール(OSBT)を作成されたという話でした。しかもこの規模のアプリをお一人で作られたのだとか。。すごい。
話を聞いているだけでもかなり使い勝手が良さそうで、自分も触ってみたいと感じました。CIの中に組み込むことが出来るのも最高ですね。
また、デモの際、ツール上のシナリオと同時に、攻撃者とユーザーなど登場人物を交えた実際の攻撃シナリオについても解説があり、各シナリオを簡単に理解することが出来ました。
最後の質疑応答で「Attacker Serverへの通信を外部インターネットに出さず、Burp等を通して内部だけで解決する機能はあるか?」という質問がありましたが、現時点では非対応とのことです。